Packet-based data communication protocols are used extensively for both automated and non-automated communication across various types of wired and wireless data networks. It is often desirable to provide a certain level of security for such communication, for example to protect sensitive data and/or to authenticate the origin of the data. Moreover, it is also desirable to reduce certain communication overheads.
The protocols most used on the Internet today include the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) which, while a number of alternatives exist, are widely carried via the Internet Protocol (IP). TCP provides a number of functions not provided by UDP. For example, TCP can be used to ensure that data packets are submitted by a source node at a rate supported by the network and destination node, data packets can be transmitted to a destination node and reassembled in an intended sequence, and that data packets lost can be detected and corrected. UDP does not provide the sequencing or flow control of TCP. UDP is often used when loss of a limited number of data packets does not corrupt the function of the communication. For example, UDP has been used for data packets carrying voice or video data.
Standardized security protocols (e.g. TLS (Transport Layer Security), SSL (Secure Socket Layer), and IPSec (Internet Protocol Security)) are typically inefficient when used for Machine-to-Machine (M2M) traffic. Standardized security protocols have a high perceived credibility due to their wide and long successful adoption. However, based on the nature of a given communication, they could prove to be slow and cumbersome.
Some typical M2M traffic can be modeled by small mobile originated (MO) burst of packets with long (>5 minutes) pauses between bursts. Most wireless M2M traffic goes through a NAT (Network Address Translator) device, which could be governed by a mobile network operator. NAT is typically used to connect network nodes that have private IP addresses to a network using public IP addresses. Private and public IP addresses are defined in the Internet Engineering Task Force (IETF) document, RFC 1918. NAT is described in a number of documents, for example, in IETF documents, RFC 2663 and RFC 3022. Due to M2M traffic patterns (long pauses between bursts), for every mobile originated transaction, the server will see a different source (SRC) Port number and SRC IP address because the NAT device has typically timed out on the address and port bindings. It is not possible to know for sure when the NAT releases its port and address bindings.
Servers implementing TLS, for example, use the SRC IP address and SRC Port numbers of incoming packets as a unique binding to the security parameters (secret key and other state information). When the NAT changes the SRC Port or IP address, (for example due to timeout and re-establishment of a NAT binding) the server can no longer look-up the security parameter for that session. TLS has a resume mechanism that can be used when this occurs, to look up the session keys, but the resume mechanism requires about 332 bytes of data and over three messages resulting in longer round trip time. Thereby, making the resume mechanism complicated, non-deterministic, and inefficient for traffic involving long pauses between bursts.
U.S. Pat. Nos. 7,917,758, 7,529,933 and 7,587,598 describe aspects of authentication and re-authentication/resuming of TLS sessions. However, the overhead involved in such resume sessions is high enough for it to pose problems for M2M traffic with long pauses between bursts.
Therefore there is a need for a security authentication protocol that over comes one or more of the problems in the prior art.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.